第20章 XPの適用
#エクストリームプログラミング
XPをチームに適用するには、数年単位でかかること。最初は大きな改善があるが、準備段階にすぎないこと
ソフトウェア開発にはムダが多い。そのムダは、チームの行動よりも信じていることや感じていることにあることもある。そのようなムダを気付けるようにするのがXP
XPを使えば問題を解決するものではない。XPの自身のスタイルに反映させて、自身で問題を解決していくもの
XPの採用方法は人それぞれである。XPの価値・原則・プラクティスの中から自分で選択して、採用していく
XPを適用すると古いやり方に戻ってしまう可能性がある。
XPの価値・原則・プラクティスを誤った使い方をして、チーム全体のストレスがかかることで、過去の習慣にもどることはよくある。こうなると後戻りが難しくなる
XPチームの働き方は他の働き方と異なるので、XPチームが否定的にみられ解散する可能性がある。そのため、XPを擁護してくれる経営幹部のサポンサーを探したり、説明責任を果たす必要がある
XPチームはすばらしい仕事をするが、ウォーターフォール型のチームと比較的したとき、ウォーターフォール型のチームは、献身的な姿勢があると見られ、XPチームは社会的・政治的に否定的な影響をあたえる可能性があると見られることがある
組織を変革するには、まず自分を変えてから、成果をチームに共有する。でないと、リスペクト不足の状態になり、チームの信頼関係は崩れていく
テストファーストプログラミングを学んでから、チームと共有する
チームでストーリー単位の見積もりと開発を学んでから、組織内の顧客にストーリーを選んでもらう
組織ないで安定してソフトウェアかを予測どおりにデプロイすることを学んでから、組織外の顧客に計画づくりを加わってもらう
継続的改善というと、絶え間なく改善を続けるのではなく、以下のステップで行う
1. 継続的に注意してフィードバックを受ける
2. 積極的に改善を受け入れる
3. 改善する
4. 効果を観察する
5. 習慣として定着させる
改善するときにプラクティスを取り入れた後に、うまくいく場合とうまくいかない場合がある。うまくいかない場合は、別の問題がある可能性があるので、もとに戻して根本的な問題をに取り組む
改善で劇的に変化するには、以下の条件が必要
価値の統一
チームと組織がXPの価値を認識している
苦痛
解雇やデプロイの失敗などが喪失感を最近経験している。苦痛の記憶があれば、劇的な変化をもとめる
このような状況に置かれていれば、変化させる絶好の機会。
コーチの選択
コーチは改善する箇所を特定して、対処するための実験をリードしていく必要がある。
経験が豊かなコーチの方がいいが、XPは経験が少ないコーチでもチームの経験から改善点を見出すことはできる
コーチはリーダーシップは必ず必要
コーチはチームに対して、継続的な改善を促す必要がある。チームメンバーがプラクティスを忘れている時には、使う気にさせるような発言をする
コーチの選択は重要かつ困難。既存の価値とXPの価値を両方にリードし続けていく必要がある
コーチは自力では簡単に学習できないことを教えれるだけのスキルが必要に
コーチはチームに対して依存ではなく自律を促すべき。コーチがいなくなっても、持続可能な、利益性の高い、安定した、楽しいソフトウェア開発の道を自分で見つけることができるチームにしていく必要がある。
XPを使うべきではない時
既存の価値とXPの価値が両立できない組織は、XPを使うべきではない
既存の価値がXPの価値の真逆の場合は、改善よりもトラブルが発生することになる